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Section 

Scope 
1 General requirements 
2 Context 
3 Goal 
4 Functional Objective 
5 Performance Requirements 
6 Verification Requirements 
E 

Scope 


These Rules are applicable to Engineering Systems that use software and are subject to Lloyd’s Register’s (hereinafter referred to 
as ‘LR’) Rules. These Rules apply to the Production of Software for the implementation of Relevant Hazard Requirements. Any 
other requirements are not within the scope of these Rules. Assessment of software independently of the Engineering System is 
not within the scope of these Rules. This definition includes all software regardless of the device on which it is stored or executed, 
or whether it is designed to have user interaction. 


| Section 7 
General requirements 


1.1 Definitions 


1.1.1 The following definitions are applicable to these Rules: 


Argument An Argument explains why something can be deduced as true from supporting evidence. See ISO 
15026-2 2011: Systems and software engineering — Systems software assurance, Part 2: Assurance 
case. 


Engineering System See Rules and Regulations for the Classification of Naval Ships, Vol 2, Pt 1, Ch 1, 3.1 Categories. 
Justification A Justification gives the reason that something has been used or applied. See ISO 15026-2: 2011. 


Producer of Software The organisation that is responsible for delivering the software as part of an Engineering System. This 
may be the same organisation that delivers the Engineering System. In respect of commercial off- 
the-shelf (COTS) software and equipment, the Producer of Software might be the original developer 
or supplier, an organisation reselling or acting as an agent for the original developer or supplier, or an 
integrator of multiple Software Products. 


Production of Software The process of interpreting requirements and realising those requirements as a Software Product by 
using suitable software lifecycle steps and applying the requirements of quality, safety and other 
management systems. Production of Software includes all lifecycle phases from requirements 
(including Relevant Hazard Requirements) to support for system integration and system testing. 
Where iterative or cyclical lifecycles are used, the Production of Software includes all iterations or 
cycles. The Production of Software includes tailored lifecycle phases where Existing or Modified 
Software is used. 


Relevant Hazards The hazards related to the necessity for the Engineering Systems as described for the different 
categories in the Rules for Naval Ships, Vol 2, Pt 1, Ch 1, 3.1 Categories. 
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Relevant Hazard Cause The cause of a Relevant Hazard. It should be noted that while Relevant Hazards are associated with 
the system level, Relevant Hazard Causes or contributions to Relevant Hazard Causes can come 
from any level, including the software level. 


Relevant Hazard Requirements Software requirements which cover how the software mitigates a Relevant Hazard Cause including, 
but not limited to: 


(a) specific functional behaviour to mitigate Relevant Hazard Causes, fault indications, accuracy 
and response times; 

(o) what it must not do; and 

(c) the degree of reliance placed on the achievement of the Relevant Hazard Requirements. 


A Relevant Hazard Requirement can be separated into components corresponding to sub-systems, 
each of which is itself called a Relevant Hazard Requirement. 


Software Intellectual creation comprising the programs, procedures, data, rules and any associated 
documentation relating to the operation of a data processing system or complex hardware, where 
complex hardware includes but is not be limited to custom micro-coded components including 
Application Specific Integrated Circuits (ASIC), Programmable Logic Devices (PLD), Field 
Programmable Gate Arrays (FPGA), or similar electronic technologies. 


Software Development Status A category assigned to software that is to be one of the following: 


(a) New - Software that is totally or significantly a new development. 

(o) Existing - Software that is to be used without modification. Existing Software includes, but is not 
limited to: operating system, third party communications protocols, graphics libraries, and 
reused supplier-developed code. 


Existing Software includes, but is not limited to: operating system, third party communications 
protocols, graphics libraries, and reused supplier-developed code. 


(a) | Modified - Software based on an Existing Software Product but changed for the system being 
assessed against these Rules. Modifications can range from setting/configuration changes to 
modifications that require the software to be recompiled. 


Note Configuration of Existing Software does not alter its function, only specified characteristics such 
as changing set points. Configuration of Modified Software might cause a different algorithm to be 
executed. 


Software Product Software considered by its supplier to be an individual entity. For example, the software for an 

Engineering System developed as a core, generic product with specific applications using the core 
as a service would be a single deliverable. However, for the purposes of these Rules, the core and 
applications are separate products. 
Software will still be considered as part of a whole Engineering System to assure that the combined 
elements meet all Relevant Hazard Requirements. Therefore, when a software system is separable 
into Software Products (as described above) the software system is to be considered a Software 
Product in its own right. 


Software Production Products All deliverables and non-deliverables necessary for the Production of Software. Software Production 
Products include, but are not limited to: the delivered software, installation/configuration data, user or 
maintenance documentation, design documentation, validation, verification, and other assurance 
documentation and records. 


Software Production Standard An international or national standard to be applied to the Production of Software. 
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E Section 2 


Context 


2.1 
2.1.1 The following general model of responsibilities is assumed for Engineering System procurement, see Figure 1.2.1 
Software Rules process diagram 


(a) 
(b) 


Context 


System level — responsible for specifying, procuring, integrating and implementing Engineering Systems within the ship; 
Engineering System level — responsible for delivering a specific Engineering System including specifying, procuring, and 
integrating its separate elements (which might include software), delivering the Engineering System, and supporting system 
level activities as necessary; 

Software level — responsible for implementing and delivering a software element of an Engineering System, and supporting 
higher level activities as necessary. 
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Note This diagram is to illustrate the key Production of Software activities in a systems context. 


Control measures for Relevant Hazards not provided through software are not shown. 


2:1:2 The responsibility for integrating a Software Product with the target hardware is to be agreed between the Engineering 
System level and the Software level as part of any contract or other statement of works. Irrespective of who has responsibilities, 
the relevant requirements of these Rules are applicable. 


2.1.3 Identification of Relevant Hazards and associated Relevant Hazard Requirements is to use appropriate analysis 
techniques involving risk assessment. Relevant Hazard Requirements can be specified by reference to recognised National or 
International Standards such as IEC/ISO 31010 Risk Management — Risk Assessment techniques, or similar, acceptable to LR. In 
such cases, it should be demonstrated that all Relevant Hazards are addressed for the specific application. The Relevant Hazards 
and their causes are to be identified at the System level and/or the Engineering System level. 


2.1.4 There is to be a documented process that results in verified Relevant Hazard Requirements being defined for the 
Software Product. 


251.5 Although not always the case, typically the whole ship is regarded as a System comprising one or more Engineering 
Systems, any of which may contain one or more separately delivered Software Products. When the System includes features 
provided by elements external to the vessel the scope of the System is to include those external elements. Functionality may be 
distributed across multiple Engineering Systems. 


2.1.6 The word ‘software’ refers to the specific Software Product which is subject to appraisal against these Rules. If more 
than one Software Product is proposed to implement an Engineering System, each Software Product is to have requirements 
specified separately under these Rules. Before there is any realisation of a Software Product, the word ‘software’ refers to the 
intended Software Product. 


2.1.7 Where multiple Software Products are used for the implementation of one Engineering System, the Engineering System 
level organisation is responsible for their integration. In such cases, the Engineering System level organisation is considered to be a 
Producer of Software and is therefore to comply with the requirements of these Rules as applicable to the reduced scope of its 
activities. Where the reduced scope leads to derogations of the Rules, they are be agreed with LR at the earliest practicable stage 
in the Production of Software, and at least prior to the end of the requirement specification stage. 


| Section 3 


Goal 
3.1 Goal 
3.1.1 The use of software as an implementation technology for an Engineering System is not to compromise the satisfaction 


of the Rules applicable to that Engineering System. 


a Section 4 
Functional Objective 


4.1 Functional objective 


4.1.1 To manage: 


(a) the realisation of all Relevant Hazard Requirements; and 
(o) the risk arising from the use of software as an implementation technology for Engineering Systems. 
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a Section 5 
Performance Requirements 


5.1 General requirements for the production of software 


Sabet This Section is applicable to all Software Development Statuses. 


5.1.2 The verified Relevant Hazard Requirements and the requirements for the satisfaction of the relevant Naval Administration 
are to be provided to the Producer of Software by the Engineering System level stakeholder. 


5.1.3 It is to be determined whether and how the failure or unspecified behaviour (see Note 1) of the software could credibly 
result in: 


(a) an event that escalates to a Relevant Hazard; 
(o) impairment of the mitigation of a Relevant Hazard; or 
(c) impairment of recovery from a Relevant Hazard. 


5.1.4 The conclusions of Ch 1, 5.1 General requirements for the production of software 5.1.3 are to be communicated to 
those responsible at the Engineering System level and, where they deem it appropriate, up to higher System levels as necessary to 
allow a design to be developed where the software does not result in any of Ch 7, 5.1 General requirements for the production of 
software 5.1.3. 


5.1.5 When an alternative design removing the software as a cause of Ch 7, 5.1 General requirements for the production of 
software 5.1.3 is not provided at the Engineering System or System level, additional Relevant Hazard Requirements are to be 
specified for the software to achieve the necessary mitigation. The specification of the new Relevant Hazard Requirements is to 
satisfy the requirements of Ch 7, 2.1 Context 2.1.3 and Ch 1, 2.1 Context 2.1.4. 


Note 1. Failure means that the software does not perform its function at all. Unspecified behaviour means the software 
performs its function partially or incorrectly. 


Note 2. Compliance with this Section may require support from System level and/or Engineering System level stakeholders. 


5.2 Production of software 


5.2.1 When there is one or more Relevant Hazard Requirement, the Production of Software is to demonstrate that the 
Relevant Hazard Requirements have been met. 


5.2.2 An Argument, supported by a body of evidence, that provides a compelling, comprehensible and valid demonstration 
that the functional objective identified in Ch 1, 4 Functional Objective has been met, is to be made and documented. 


5.2.3 Configuration management satisfying the requirements of ISO 10007:2003: Quality management systems — Guidelines 
for configuration management, or an alternative standard acceptable to LR, is to be used during the Production of Software. 


5.2.4 Software is to be produced using a quality management system that satisfies the requirements of 9001:2008: Quality 
management requirements using the guidance of ISO 90003:2014: Software engineering — Guidelines for the application of ISO 
9001:2008 to computer software. When the software implements safety requirements, the part of the safety management system 
applicable to the Production of Software is to be within the scope of the quality management system. 


5.2.5 The Producer of Software is to identify and justify the Software Production Standard to be used.The Justification is to be 
documented and is to demonstrate that the chosen Software Production Standard is appropriate for the degree of reliance placed 
on the software by the Relevant Hazard Requirements. 


5.2.6 The Producer of Software is to submit the Justification for the chosen Software Production Standard to LR for 
consideration. 


5.2.7 A plan for the Production of Software is to be formulated, documented, and used to direct the Production of Software. If 
the plan is incorporated into another document, the strategy and the structure of the plan, with a route map to other 
documentation, are to be documented separately. The level of detail in the plan is expected to increase as the project progresses 
through the lifecycle phases of the Production of Software. The plan is to be complete with respect to each lifecycle phase before 
the phase is initiated. 


5.2.8 The plan for the Production of Software is to be submitted to LR for consideration in sufficient time to allow for resolution 
of any comments prior to implementation of the activities specified by the plan. 


5.2.9 The plan for the Production of Software is to: 
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(a) include all activities for the Production of Software, including production of the Argument and supporting evidence referred to 
in Ch 1, 5.2 Production of software 5.2.2; 


(bo) include the processes, methods, techniques and tools required by the agreed Software Production Standard and applicable 
to the degree of reliance placed on the software by the Relevant Hazard Requirements; 

(c) take account of factors which influence the introduction of errors, such as the size, complexity, and novelty of the software; 

(d) justify deviation from the requirements of the Software Production Standard; and 

(e) justify and record the Software Development Status as New, Modified, or Existing. For a status of Modified, the Justification is 
to demonstrate that a status of New is not appropriate using an assessment that is to include, but is not limited to: 


(i) the proportion of modification of the original product 

(ii) | whether the modification is a new or modified Relevant Hazard Requirement 

(iii) | the number of interactions within the software effected by the modification 

(iv) the complexity of the function being modified or added 

(v) whether the modification represents a fundamental change to the design, such as a change to the scheduling regime, or 
key data structures 


(vi) the knowledge within the team making the change modification and the status of the design documentation 
5.2.10 The Software Development Status of the software is to be agreed by LR. 


5.2.11 When there are changes to Relevant Hazard Requirements which affect the plan for the Production of Software, the plan 
is to be revised. 


5.2.12 | When the implementation of the Software Production Standard is changed, the plan for the Production of Software and 
its Justification are to be updated and submitted to LR for consideration in sufficient time to allow for resolution of any comments 
prior to implementation of the activities specified by the plan. The Justification is to demonstrate that deviations do not undermine 
compliance with the Relevant Hazard Requirements or Ch 7, 5.1 General requirements for the production of software 5.1.3. 


5.2.13 The Production of Software is to be performed in accordance with the Software Production Standard and the plan for 
the Production of Software. 

5.3 Modified software 

5.3.1 This Section of the Rules is additionally applicable to software with a Software Development Status of Modified. 


5.3.2 The modification of Software Products is to be undertaken in accordance with defined modification processes which are 
part of the supplier's quality management system. 


5.3.3 The impact of the modification on previously developed Software Products is to be assessed and used to tailor the 
Producer of Software’s management systems for the specific software modification. Management systems include its quality 
management system, safety management system and engineering management system. Ch 1, 5.3 Modified software 5.3.3 is to 
be repeated during the development to ensure that, as the development progress, the actual impacted elements of the products 
are identified and the suitability of the management system is maintained. 


5.4 Existing software 
5.4.1 This Section of the Rules is applicable to software with a Software Development Status of Existing. 


5.4.2 All requirements applicable to New Software are applicable to Existing Software, except those directly related to the 
production of code; that is software design, coding and testing of the code at a level lower than a complete Software Product. 


5.4.3 The requirements of Ch 7, 5.1 General requirements for the production of software 5.1.5 only apply where any 
additional Relevant Hazard Requirements can be implemented through configuration of the Existing Software or by providing New 
Software to work in co-operation with the Existing Software. 


a Section 6 
Verification Requirements 


Verification Requirements 


Note The Verification Requirements of Ch 1, 6 Verification Requirements are additional to the Performance Requirements of 
Ch 1, 5 Performance Requirements, which are required to be satisfied in all cases. 
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6.1 General requirements for the production of software 


6.1.1 The Relevant Hazard Requirements are to be derived from: 


(a) System and Engineering System level hazard identification and risk assessment activities; and 
(o) allocation of Relevant Hazards at the Engineering System level to specific components. 


See also Ch 1, 2.1 Context 2.1.2. 


6.1.2 Where it is impractical to implement the Relevant Hazard Requirements, the Producer of Software is to communicate 
this to the Engineering System and higher System level stakeholders and, where necessary, the derivation of Relevant Hazard 
Requirements is to be repeated at the Engineering System and System levels. See also Ch 1, 6.1 General requirements for the 
production of software 6.1.5. 


6.1.3 The approaches to be used for deriving Relevant Hazard Requirements (see Ch 7, 6.7 General requirements for the 
production of software 6.1.1), and a Justification of their adequacy, are to be documented. 


6.1.4 The Relevant Hazards, Relevant Hazard Requirements and traceability between them are to be documented. 


6.1.5 At the earliest practicable stage in the Production of Software, to be at least prior to the end of the requirement capture 
stage, and agreed with LR, an analysis is to be performed by the Producer of Software to determine compliance with Ch 1, 5.7 
General requirements for the production of software 5.1.3. The approach for this analysis, together with a Justification of its 
adequacy, is to be documented. 


6.1.6 The analysis required by Ch 7, 6.1 General requirements for the production of software 6.1.5 is to be re-evaluated 
during the Production of Software to address emerging properties of the software. The Producer of Software is to agree with LR 
the criteria for a re-evaluation of the analysis. A Justification of the adequacy of the criteria is to be documented. 


6.1.7 Evidence is to be documented that the analysis required by Ch 1, 6.1 General requirements for the production of 
software 6.1.5 has been performed. 


6.1.8 Where there is any change in the results of the re-evaluation required by Ch 1, 6.7 General requirements for the 
production of software 6.1.6, Ch 1, 5.1 General requirements for the production of software 5.1.4 is to be reapplied. 


6.1.9 The documentation recording the Relevant Hazards, Relevant Hazard Requirements and the traceability between them 
is to be updated to include any Relevant Hazards emerging from the analysis required by Ch 1, 6.1 General requirements for the 
production of software 6.1.5 and Ch 1, 6.1 General requirements for the production of software 6.1.6. 


6.1.10 The requirements of Ch 7, 5.1 General requirements for the production of software 5.1.5 apply in full with the additional 
requirement identified in Ch 1, 6.1 General requirements for the production of software 6.1.17 below. 


6.1.11 The documentation recording the Relevant Hazards, Relevant Hazard Requirements and the traceability between them 
is to be maintained when Relevant Hazard Requirements are changed, added or removed. 


6.2 Production of software 
6.2.1 When there is one or more Relevant Hazard Requirement to be satisfied by the software, the Production of Software is 


to be managed in accordance with the requirements of Ch 1, 5.2 Production of software, Ch 1, 5.3 Modified software and Ch 7, 
5.4 Existing software, as appropriate to the Software Development Status. 


6.2.2 The Production of Software is to be managed so that it is demonstrable, appropriate to the degree of reliance placed on 
the software by the Relevant Hazard Requirements, that: 


(a) the additional Relevant Hazard Requirements identified through the analysis required by Ch 1, 6.1 General requirements for 
the production of software 6.1.5 and Ch 7, 6.1 General requirements for the production of software 6.7.6 are valid and the 
set of requirements is complete; 

(o) the software satisfies the Relevant Hazard Requirements including, but not limited to, that it provides the necessary functional 
behaviour, it communicates faults and failures, and it provides the required accuracy and response times; 

(c) the software does not result in the outcomes identified in Ch 7, 5.1 General requirements for the production of software 
5.1.3; and 

(d) the delivered software will be able to be relied upon to the degree placed on it by Relevant Hazard Requirements. 


6.2.3 An Argument, supported by a body of evidence that provides a compelling, comprehensible and valid demonstration 
that the following criteria have been met, is to be made and documented that demonstrates: 


(a) the validity and completeness of the Relevant Hazard Requirements. The satisfaction of this clause might require support 
from the System level and/or Engineering System level stakeholders; 
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(b) that the software implementation delivers its Relevant Hazard Requirements; and 


(c) the appropriateness and sufficiency of management, production, and assurance processes used for the Production of 
Software. 


The Argument is to be included in, or referenced by, the Arguments produced at the Engineering System and System level. 


6.2.4 Where any of Ch 1, 6.2 Production of software 6.2.3 cannot be demonstrated, it is to be demonstrated that the risk 
associated with the Relevant Hazards has been mitigated through some other means and/or any residual risk is tolerable. 


6.2.5 When an Argument or supporting evidence makes use of an existing Argument or supporting evidence, the validity of 
the existing Argument or supporting evidence to the new application is to be demonstrated. 


6.2.6 Configuration management used during the Production of Software is, as a minimum, to: 


a) uniquely identify constituent parts of the software and associated Software Production Products; 
b) allow accurate and consistent cross-referencing between Software Production Products; 

) provide controls for the use of partially developed or interim Software Production Products; 
d) prevent unauthorised items from entering service; and 

) identify and document the versions of software deliverables. 


6.2.7 If a Producer of Software is certified to ISO 9001 and the scope of certification includes its production of software 
activities, a copy of the certificate and the scope of certification are to be submitted to LR. 


6.2.8 If a Producer of Software is not certified to ISO 9001 or its certification does not explicitly include its production of 
software activities, a Justification for the adequacy of the quality management system to be used for the Production of Software is 
to be submitted to LR for consideration. 


6.2.9 The Producer of Software is to allow audits of the Production of Software and other parts of its quality management 
system if LR requires such an audit to confirm the Production of Software is in compliance with ISO 9001. Where audits are 
required the guidance of ISO 90003:2014 is to be followed. 


6.2.10 A Justification for the plan for the Production of Software is to be produced that covers: 


(a) demonstration that, where there is deviation from the Software Production Standard, either the principles of any parts being 
deviated from are met by other means, or the deviation will have no effect on the achievement of the degree of reliance 
placed on the software by the Relevant Hazard Requirements; 


(o) the selection of suitable processes, methods, techniques and tools for the Production of Software including assurance 
activities which support the achievement of the required degree of reliance on the software by the Relevant Hazard 
Requirements; 


(c) the factors identified in Ch 1, 5.2 Production of software 5.2.9; and 
(d) demonstration that deviations do not undermine assertions about: 


(i) compliance with the Relevant Hazard Requirements; 


(ii) | how the software could credibly result in the outcomes listed in Ch 7, 5.1 General requirements for the production of 
software 5.1.3. 


6.2.11 The plan for the Production of Software is to cover activities that contribute to providing assurance that the Software 
Product will achieve the degree of reliance placed on it by the Relevant Hazard Requirements, including: 


(a) A full list of software components being developed and, for each, what is required to be produced, including code artefacts, 
tools, specifications, design models, and documentation. 

(o) Identification of deliverables, including those for integration, sea trials, operations and maintenance. The satisfaction of this 
clause might require support from the System level and/or Engineering System level stakeholders. 

(c) Details of subcontracted work and how any subcontracts will be managed including how it will be ensured that the plan for 
the Production of Software will be adhered to by subcontractors. 


(d) Identification of the principal project risks arising from the Production of Software and a plan to remove or mitigate the risks. 
(e) A definition of the software lifecycle to be utilised. 
(f) Details of the processes, methods, techniques and tools to be used for each part of the software lifecycle, including: 


(i) | The pedigree of chosen tools and design methods; 
(ii) | The identification of specific software architecture and software design features appropriate to the degree of reliance 
being placed on the software delivering the Relevant Hazard Requirements; 
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(iii) |The verification to be performed including measures to provide assurance that the contribution made by each lifecycle 
phase to the translation of the Relevant Hazard Requirements into the Software Product has been done correctly and 
completely; and 

(iv) The validation to be performed to demonstrate the Software Product realises its Relevant Hazard Requirements. 

(9) A list of key personnel, and their responsibilities, in the software development team and in any subcontractor’s team. 

(h) The competences required for the Production of Software including experience of the domain and using the selected 
processes, methods, techniques and tools, and a plan for filling any competence gaps within the team producing the 
software. 

(i) | The techniques and tools to be used for analysis of the software architecture and design to confirm that the specific design 
features which are implemented by functions to satisfy the Relevant Hazard Requirements, will work as specified in all modes 
of operation and failure conditions. 

(i) Details of the code implementation and coding standards to be applied to ensure that the software code is implemented 
using features that are capable of achieving the degree of reliance placed on the software by the Relevant Hazard 
Requirements. 

(k) Validation activities to demonstrate that the functions of the software specifically implemented to satisfy the Relevant Hazard 
Requirements will operate as intended in all feasible operating scenarios, including: 


(i) testing to demonstrate that hazard mitigations work as intended; 
(ii) | testing to demonstrate that under any condition the software does not cause the outcomes listed in Ch 1, 5.1 General 
requirements for the production of software 5.1.3; 
(iii) | testing to demonstrate that functions implemented to satisfy the Relevant Hazard Requirements work in all credible 
operating scenarios; and 
(iv) where validation techniques alternative to testing are to be used, details of the techniques to be applied and how they 
will deliver the objectives of items (i) to (iii). 
(l) | The processes to be used to transition from one lifecycle phase to the next, including: 
(i) | measures to assess lifecycle phase completeness for individual Software Production Products and for all products; 
(ii) | authority required to approve transition to the next lifecycle phase; 
(iii) criteria for transition to the next lifecycle phase; and 
(iv) for transitions to trials and in-service operation, how it will be determined that the software has achieved sufficient 
reliability. 
6.2.12 The Producer of Software is to allow an audit of its capability for Production of Software to facilitate LR’s software 
assessment planning. 
6.2.13 | The Producer of Software is to co-operate in the formulation of LR’s assessment plan, which will specify: 
(a) any additional documentation to be submitted and the purpose of the submission; 
(o) any additional audits to be performed by LR; and 
(c) activities to be witnessed by LR. 


LR and the Producer of Software are to agree on items (a) to (c). 


6.3 Modified software 


6.3.1 When it is proposed to use Modified Software in the implementation of an Engineering System, the Argument required 
by Ch 1, 5.2 Production of software 5.2.2 is to include why the unmodified parts of the software are fit for purpose. The Argument 
is to include how the Relevant Hazard Requirements are satisfied by the software and is to refer to evidence, both available and to 
be derived during the production process, that supports the Argument. 


6.3.2 The Producer of Software is to agree with LR the criteria to be used to determine when to re-evaluate the impact of the 
modification as required by Ch 7, 5.3 Modified software 5.3.3. 


6.3.3 Records of the evaluation of the impact of modification are to be retained by the Producer of Software. 


6.4 Existing software 


6.4.1 The following general requirements are applicable to all Existing Software. 


6.4.2 When it is proposed to use Existing Software in the implementation of an Engineering System, the Argument required by 
Ch 1, 6.2 Production of software 6.2.3, is to include why the Existing Software is fit for purpose. The Argument is to include how 
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the Relevant Hazard Requirements are satisfied by the Existing Software, and is to refer to evidence, both available and to be 
derived during the production process, that supports the Argument. 


6.4.3 Evidence supporting the Argument required by Ch 7, 6.2 Production of software 6.2.3 is to be collected and maintained 
by the Producer of Software during the Production of Software. 


6.4.4 When the Argument required by Ch 7, 6.2 Production of software 6.2.3 does not adequately demonstrate satisfaction of 
the Relevant Hazard Requirements, the Producer of Software is to agree with LR the additional assurance necessary to produce a 
valid Argument. Consideration is to be given to: 


a) activities to be performed by the Producer of Software to ensure that the Relevant Hazard Requirements will be satisfied; 
b) additional documentation to be submitted and the purpose of the submission; 

) additional evidence to be submitted and its relationship to the Argument; 

d) additional audits to be performed by LR; and 

) activities to be witnessed by LR. 


6.4.5 Where the additional assurance in Ch 1, 6.4 Existing software 6.4.4 is required, it is to be included in the plan for the 
Production of Software. 


6.5 Software previously assessed and certified 


6.5.1 This Section is applicable when software has been previously assessed and certified and the Argument for the suitability 
of the software relies on the previous certification. 


6.5.2 Any certificates, design appraisal documents, or similar, for the software, together with supporting documentation, are 
to be submitted for assessment of validity for the proposed application. 


6.5.3 The Argument required by Ch 7, 6.2 Production of software 6.2.3 is to demonstrate why the previous certification 
applies to the proposed application. Consideration is to be given to the applicability of: 


(a) the configuration(s) of the previously certified software; 
(o) the operating scenario relevant to the previously certified software; and 
(c) the standard against which the previous certification was performed. 


6.5.4 If the previous certification indicated an expected level of risk reduction or the degree of reliance that could be placed on 
the software, it is to be equivalent or higher than the Relevant Hazard Requirements for the proposed application. 


6.5.5 The Producer of Software is to provide a summary of modifications and updates to the software since the previous 
appraisal, including an analysis of the impact on the degree of reliance that can be placed on the software achieving its Relevant 
Hazard Requirements. 


6.5.6 The Producer of Software is to demonstrate that any conditions placed on the use of the software have been met. 
Conditions might need to be imposed at the Engineering System or the System level. 


6.6 Software previously used and trusted with development data available 


6.6.1 This Section is applicable when software has been previously used and trusted with development data available, and 
the Argument for suitability of the software relies on the development data. 


6.6.2 When the Argument required by Ch 1, 6.2 Production of software 6.2.3 is based on ‘Software previously used and 
trusted with development data available’, the development data, which is the evidence supporting the Argument, must be for the 
same software version as that of the proposed application. 


6.6.3 The Producer of Software is to allow LR access to the development data so that LR can assess the level of compliance 
of Existing Software with the Rules. The assessment might include, but is not limited to, discussions and on-site document 
reviews. Where Production of Software has included the use of subcontractor(s), the Producer of Software is to facilitate access to 
data held by the subcontractor(s). 


> 


6.6.4 The assessment required by Ch 7, 6.6 Software previously used and trusted with development data available 6.6.3 is to 
be used to identify any additional assurance requirements. 


6.7 Software previously used and trusted with previous-use data available 


6.7.1 This Section is applicable when software has been previously used and trusted with previous-use data available, and the 
Argument for suitability of the software relies on the previous-use data. 
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6.7.2 When the Argument as required by Ch 7, 6.2 Production of software 6.2.3 is based on ‘Software previously used and 
trusted with previous-use data available’, the previous-use data, which is the evidence supporting the Argument, must relate to 
use of the software under the same conditions as the proposed application including, but not limited to, running on the same 
hardware, operating system (if applicable), and functional requirements. 


6.7.3 Where the software under assessment provides only part of an Engineering System’s software solution, the Production 
of Software is to include validation of the Software Product as part of the total software solution. The supplier of software is to 
achieve this requirement through communication with the supplier of the Engineering System and is to mitigate the risk of its 
Software Product not working within the total software solution. 


6.8 Documentation and information 


6.8.1 This Section details the requirements applicable to the documentation that is to be provided to LR as defined by Ch 7, 
6.9 Documentation required for design review. 


6.8.2 Documentation is to be submitted electronically and is to be searchable. Where specialist computer tools are required to 
read documentation, the tool(s) to be used are to be agreed with LR. 


6.8.3 If documentation to be submitted is to be produced or released in stages, or is updated, the producer of the 
documentation is to agree with LR which specific Formally Released versions are to be delivered to LR. 


6.8.4 Documentation is to be submitted in sufficient time to allow LR’s comments to be accommodated in revised 
documentation or implementation of activities. 


6.8.5 If documentation required by Ch 1, 6.9 Documentation required for design review is incrementally or iteratively released, 
the Producer of Software is to ensure that the scope of the documentation and the status of the intermediate products to which 
the documentation refers are clearly recorded. 


6.8.6 The Argument required by Ch 7, 6.2 Production of software 6.2.3 is to be produced incrementally so that its strategy 
and basis can be agreed with LR in advance of the delivery of the completed document. The strategy and basis may be submitted 
separately in advance of the Argument. 


6.8.7 Specific documents to be produced are not prescribed. This is to allow the Producer of Software and other relevant 
stakeholders to use, as far as possible, their normal documentation structure. The specific documents used to meet these Rules 
requirements are to be agreed with LR. 


6.9 Documentation required for design review 
6.9.1 The following documentation is to be submitted for consideration: 


a) Adescription of, and Justification for, the approaches to be used for deriving Relevant Hazard Requirements; 

b) A description of, and a Justification for, the approach used to determine the effects of the software on the Relevant Hazards; 

c) The Argument required by Ch 7, 6.1 General requirements for the production of software 6.1.3; 

d) Where the scope of certification explicitly includes its production of software activities, a copy of the Producer of Software’s 
ISO 90008 certificate and the scope of certification, or a statement demonstrating that the quality management system used 
for the Production of Software is compliant with the requirements of ISO 90003 or otherwise adequate, as applicable; 

(e) The plan for the Production of Software together with its Justification; 

(f) The Argument for why the software is fit for purpose, see Ch 7, 6.4 Existing software 6.4.2. 


Fe an 


6.9.2 The following documentation is to be made available to LR on request: 


(a) The records and results of compliance with Ch 1, 6.1 General requirements for the production of software 6.1.3; 

(o) The supporting evidence confirming the validity of the Argument required by Ch 1, 6.7 General requirements for the 
production of software 6.1.5; 

(c) The document defining the configuration management approach to be used during the Production of Software; 

(d) The evidence supporting the Argument demonstrating why the software is fit for purpose, see Ch 1, 6.4 Existing software 
6.4.3; and 

(e) The records of the analysis of modification of Existing Software Products, see Ch 7, 6.3 Modified software 6.3.3. 


6.9.3 The documentation recording the Relevant Hazard Requirements, the traceability of the Relevant Hazard Requirements 
and the Relevant Hazards, is to be submitted to LR at the same time as it is provided to the Producer of Software. 
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